Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[BugFix] Fix incorrect execution plan when generated column rewrite in join relation if left table and right table has the same column name (backport #52584) #52639

Closed
wants to merge 1 commit into from
Closed

[BugFix] Fix incorrect execution plan when generated column rewrite in join relation if left table and right table has the same column name (backport #52584) #52639

wants to merge 1 commit into from

Conversation

mergify[bot]
Copy link
Contributor

@mergify mergify bot commented Nov 5, 2024 •
edited by wanpengfei-git
Loading

Why I'm doing:

This problem is introduced by pr #50398. In this pr, we introduce some new rule for generated column rewriting. The basic idea is following:

  1. Collect the rewriting relation in every SELECT scope in query. (Expr -> SlotRef)
  2. Translate the expression relation into Operator mapping: ScalarOperator -> ColumnRefOperator
  3. Introduce new rule says ReplaceScalarOperatorRule, use this new rule to replace the ScalarOperator by ColumnRefOperator when generating the logical plan in optimizer.

This problem is that, ReplaceScalarOperatorRule use ScalarOperator.isEquivalent to check if a ScalarOperator hit the rule instead of using ScalarOperator.equals. ScalarOperator.isEquivalent does not check the operator id but this id will be used to identify the column with the same column name but come from different table in JOIN relation. (e.g column xx in TABLE A and column xx in TABLE B has same name but different id, in this case, ScalarOperator.isEquivalent return true but ScalarOperator.equals return false). So in this case, we will get the wrong mapping and generated a incorrect plan for generated column rewrite.

What I'm doing:

  1. Using ScalarOperator.equals instead
  2. Introduce session variables disable_generated_column_rewrite for disable the generated column rewrite if we want.

Fixes #issue

What type of PR is this:

  • BugFix
  • Feature
  • Enhancement
  • Refactor
  • UT
  • Doc
  • Tool

Does this PR entail a change in behavior?

  • Yes, this PR will result in a change in behavior.
  • No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

  • Interface/UI changes: syntax, type conversion, expression evaluation, display information
  • Parameter changes: default values, similar parameters but with different default values
  • Policy changes: use new policy to replace old one, functionality automatically enabled
  • Feature removed
  • Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

  • I have added test cases for my bug fix or my new feature
  • This pr needs user documentation (for new or modified features or behaviors)
    • I have added documentation for my new feature or new function
  • This is a backport pr

Bugfix cherry-pick branch check:

  • I have checked the version labels which the pr will be auto-backported to the target branch
    • 3.3
    • 3.2
    • 3.1
    • 3.0
    • 2.5
This is an automatic backport of pull request #52584 done by [Mergify](https://mergify.com). ## Why I'm doing: This problem is introduced by pr #50398. In this pr, we introduce some new rule for generated column rewriting. The basic idea is following: 1. Collect the rewriting relation in every `SELECT` scope in query. (`Expr` -> `SlotRef`) 2. Translate the expression relation into Operator mapping: `ScalarOperator` -> `ColumnRefOperator` 3. Introduce new rule says `ReplaceScalarOperatorRule`, use this new rule to replace the `ScalarOperator` by `ColumnRefOperator` when generating the logical plan in optimizer.

This problem is that, ReplaceScalarOperatorRule use ScalarOperator.isEquivalent to check if a ScalarOperator hit the rule instead of using ScalarOperator.equals. ScalarOperator.isEquivalent does not check the operator id but this id will be used to identify the column with the same column name but come from different table in JOIN relation. (e.g column xx in TABLE A and column xx in TABLE B has same name but different id, in this case, ScalarOperator.isEquivalent return true but ScalarOperator.equals return false). So in this case, we will get the wrong mapping and generated a incorrect plan for generated column rewrite.

What I'm doing:

  1. Using ScalarOperator.equals instead
  2. Introduce session variables disable_generated_column_rewrite for disable the generated column rewrite if we want.

Fixes #issue

What type of PR is this:

  • BugFix
  • Feature
  • Enhancement
  • Refactor
  • UT
  • Doc
  • Tool

Does this PR entail a change in behavior?

  • Yes, this PR will result in a change in behavior.
  • No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

  • Interface/UI changes: syntax, type conversion, expression evaluation, display information
  • Parameter changes: default values, similar parameters but with different default values
  • Policy changes: use new policy to replace old one, functionality automatically enabled
  • Feature removed
  • Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

  • I have added test cases for my bug fix or my new feature
  • This pr needs user documentation (for new or modified features or behaviors)
    • I have added documentation for my new feature or new function
  • This is a backport pr

@srlch @mergify
[BugFix] Fix incorrect execution plan when generated column rewrite i…
bda592b 
…n join relation if left table and right table has the same column name (#52584)

Signed-off-by: srlch <[email protected]>
(cherry picked from commit af20339)

# Conflicts:
#	fe/fe-core/src/main/java/com/starrocks/qe/SessionVariable.java
@mergify mergify bot added the conflicts label Nov 5, 2024
@mergify Mergify
Copy link
Contributor Author

mergify bot commented Nov 5, 2024

Cherry-pick of af20339 has failed:

On branch mergify/bp/branch-3.2/pr-52584
Your branch is up to date with 'origin/branch-3.2'.

You are currently cherry-picking commit af20339fc0.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   fe/fe-core/src/main/java/com/starrocks/sql/analyzer/QueryAnalyzer.java
	modified:   fe/fe-core/src/main/java/com/starrocks/sql/optimizer/rewrite/scalar/ReplaceScalarOperatorRule.java
	modified:   fe/fe-core/src/test/java/com/starrocks/sql/plan/GeneratedColumnTest.java
	modified:   test/lib/sr_sql_lib.py
	modified:   test/sql/test_materialized_column/R/test_generated_column_rewrite
	modified:   test/sql/test_materialized_column/T/test_generated_column_rewrite

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   fe/fe-core/src/main/java/com/starrocks/qe/SessionVariable.java

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

@mergify mergify bot mentioned this pull request Nov 5, 2024
Merged
24 tasks
@wanpengfei-git wanpengfei-git enabled auto-merge (squash) November 5, 2024 10:23
@mergify Mergify
Copy link
Contributor Author

mergify bot commented Nov 5, 2024

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr

@mergify mergify bot closed this Nov 5, 2024
auto-merge was automatically disabled November 5, 2024 10:23

Pull request was closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@srlch srlch

Labels
automerge behavior_changed conflicts
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@srlch